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There are many problems when developing software applications for wireless mobile 
devices (e.g. smartphones, communicators, PDAs etc.). The key problems are: 



1. there are a wide range of network connection options, such as Bluetooth, GSM, 
GPRS, IR and cable, that must be managed by the application 

2. mobile devices do not have an adequate user interface for developing software 

3. mobile devices typically have small amounts of memory and processing power, 
15 relative to laptops and desktop PCs, so die software developed must make very 

efficient use of resources. 
4- Current program m ing approaches require either very skilled programmers witii 
specialised development software (i.e. using C++ with detailed knowledge of 
mobile device Oss, e.g. SymbianOS) or make very inefficient xise of the restricted 
20 resources of die mobile phone (e.g. using Visual Basic on SymbianOS requires 

1MB runtime eng^e and typical applications are also usually more than 1MB). 



There is no good solution to solving all of these problemS. The current main option for 
addressing problems 1 and 3 is to develop low-level code, in a language such as C++, 
25 that directiy accesses all of these features on the phone. This is both difficult to learn 
and slow to develop applications for, because of the detailed knowledge and 
programming skills required. 

The current tnam option for addressing 2 is to use an emulator for die device running on 
30 a PC. This is not as rapid as it could be as the developer has to develop and test his 
application twice •- once on the emulator and secondly directiy on the device, and there 
are always differences in behavioxxr between the emulator and PC. This is especially true 
when writing networked applications as the emulator does not have the wide range of 



network connection options that are available on a phone so more testing' needs to be 
done on the device. 



SUMMARY OF THE PRESENT INVENTION 



In a first aspect, diere is a method of rapid software application development for a 
5 \vireless mobile device, comprising die step of calling modular software elements, that 
each ® encapsulate functionality required by the ^eless mobile device and (li) share a 
standard interface structure and (m) execute on the device, using a high level language 
program. 

10 Further details and aspects are g^ven in the appended Claims. 

In one implementation, modular software elements, called pipe processors, are combined 
to solve the problems of 1, 2 and 3 in a way that significantiy reduces die time it takes to 
develop networked applications for mobile devices. 

15 

Pipe processors are stand alone modules that encapsulate a range of mobile device 
functionality. Pipe processors are written efficientiy in a software code suitable for the 
phone operating system, such as C++, These pipe processors are all called from a 
standard interface stmcture, comprising the name of the pipe processor and a set of 
20 options. The results of the pipe processor are returned to the calling element using a 
standard output and standard error. 

Rapid networked application development is facilitated because: 

25 • All of the pipe processors have the same type of interface that can be called frpm 

a command-line interface, or other high-level language. This provides the 
developer witii die means of solving the network management problems of 1 but 
widiout having to learn die details of a specific networit interface or program in a 
low-level language such as C++. 

30 • All of die pipe processors can be executed on die device remotely from die PC, 

so providing the developer with a good user interface for development but 
without having to develop software first on a emulator and then for die device. 



The mod\ilat architectdre of the pipe processors means that modules can be 
included or removed as necessary. This means that software can quickly be 
developed diat also makes efficient use of the restricted resources on the mobile 
device, so solving problem 3. Odier rapid development approaches for mobile 
devices, such as using high-level languages such as Visual Basic, require large run- 
time components and hence consume large resources on the mobile device. 



The present invention hence solves the problem of rapid networked application 
development and reconfiguration, as all of the pipe processors can be called either from 
command-line, scripts, or other programming languages. Hence, required functionaUty 
can be quickly prototyped using scripting to prove the functionaUty, before being 
codified into a programming language for the application. 

This problem of rapid networked application development and reconfiguration has been 
aroxrnd for some time as mobile devices, such as PDAs, have been around for many 
years. Current approaches to this problem, such as using Java MIDP, cannot however 
fully exploit die network features of the mobile device as they are constrained by the 
high-level interfaces required to make the development quick and easy. Also, many of 
the current approaches rely on the use of emulators on the PC. The present invention 
can complement Java MIDP to overcome these limitations. 

There are three significant further advantages to the present invention: 

1. Enables programming by non-sltilled programmers. Using the set of pipe 



the phone. This can be used as a means of enabling non-skilled programmers to 
modify applications for their own use, or to quickly prototype and test an 
application that can be handed to a skilled developer for turning into a complete 
networked software application for mobile devices. 

* 

It allows someone to modify a software application when all they have is a 
mobile device, for example when they are on the train. Software can be 
developed from a PC, with a link to the mobile device. However, if the 
application is scripted on die mobile device then when you are away from your 
PC, the script can be quickly modified to create a different application, without 
the need to compilers, debuggers, emulators and the other development tools 
required for standard PC-based software development. 

Provides a single interface from a wide range of programming languages, 
including command-line and scripting interfaces, to mobile device running a wide 
range of operating systems. Hence, a programmer can choose whatever language 
they like to develop die software, and does not have to learn dififerent interfaces 
for different mobile devices. This is similar in concept to using Java MIDP as a 
basis for writing portable applications for smartphones. However, using Java 
MIDP it is not possible to write good networked applications for mobile devices 
as Java MIDP standard does not allow access to tiie necessary networked features 
on die phone. This can be achieved by extending the MIDP programming 
interface witii additional mobile-device specific interfaces, but this requires the 
developer to vinderstand die different interfaces for each phone. The proposed 
ftamework eliminates this problem by providing a common interface to the low- 
level networking and otiier phone features that is common across different 
mobile device operating-systems. 




DETAILED DESCRIPTION 



The purpose of the invention is to facilitate rapid develop of networked application 
software for mobile devices. An implementation comprises software resident on the 
different computing devices connected to die network, including mobile device, such as 
a smartphone, desktop PC and server, with an example configuration shown in Figure 1. 



Software components are required on all of the different elements in die network to 
facilitate rapid application development and deplojraent. This is illustrated by the 

10 following example for developing a networked application on the mobile device that 
enables a user to make full use of an enterprise CRM system for better customer 
relationships. To do this, software must be developed on the mobile device tiiat can 
connect to an enterprise server, that implements the CRM system and manages all of the 
customer interactions for the enterprise. The mobile device must be able to connect 

15 both over a wide area connection to the server (such as over GPRS) as well as through a 
faster local connection tiiroiagh a broadband wireless link through the PC. The limited 
user interface of the mobile device also means that the mobile device must connect easily 
widi the desktop PC to allow the user to take advantage of the large screen and keyboard 
of tiie desktop PC when die user is sitting at his or her desk. 

20 

The traditional means of developing such an application would be to develop the 
software on tiie desktop PC using appropriate development tools, such as an IDE, and 
to run and test die application on an emulator on the desktop PC. Once the software is 
successfully running on the emulator then it can be transferred to the mobile device, 
25 where it needs to be debugged again.. This„approach is_ofte.n fine-for non-networked, 
appBcation as there is littie difiFerence between the emulator and PC. However, for 
networked applications the emulator does not have die range of network, connections 



to the phone such as SMS). Hence, the developer can proceed in a much faster way for 
development of the networked application as follows: 

1. The developer chooses which of the modular set of mrix pipe processor 
components will be used for the application. 

2. The devaoper tests how the chosen pipe processors will be used from the 

command line. 

3. A simple script can be put together to put these together into a complete 
application running on the phone, again running remotely from the desktop PC. 

4. Connectivity components on the PC, such as mRouter, which may be part of 
tnriv^ are used if networked connectivity is required to, or routing through, the 
desktop PC &om the mobile device. See PCT//GB2002/003923, the contents 
of whidbi are incorporated by reference, for more details on mRouter. 

5. Connectivity components on the server are used if the server needs to connect to 
the phone. This is req\iired as the phone's IP address is not visible to the outside 
wodd S.O cannot be contacted by the server. Hence, die Relay servo: is required 
that is visible by both die phone and back-office server, to enable netwodced 
conununicadon to the server. 

The invention is implemented in technology called mrix firom Intuwave limited, mrix is 
a wireless software platform designed to significandy reduce die time to market in 
producing solutions involving smartphones by:- 

• reducing the learning curve and tiierefore opening up development to a larger 

community of developers 

• providing network OS like fadUties allowing smartphones to be treated like 

shared network components 

• providing critical "building blocks" which encapsulate complex smartphone 

functionaUty. 

mdx includes a platform agnostic remote command execution environment for 
smartphones. A command interpreter interfaces to a smartphone through a set of 
commands or "pipe processors". These are small stand-alone modules written in C++ 
or scripting languages that encapsulate a. range of smartphone functionaUty. Device 
resident mrix pipe processors (prefixed witii "mr") are provided which facilitate die 
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control and management of mxjltiple bearers (GPRS, SMS, Bluetooth, MMS, WiFi etc); 
device peripherals (such as barcode readers, pens, printers, GPS etc); other devices and 
servers; and network billing. Pipe processors can be "chained" togedier to biiild more 

* 

functionality. These building* blocks allow fast and iterative development of mobile 
5 solutions. The use of scripting languages opens up development to a much broader 
community of developers. 



mrix Architecture 

mrbc is designed around a command interpreter running on a smartphone and a 
10 command execution shell running on a remote PC or otiaer suitable platform. 

Pipe processors can be invoked remotely (like Unix commands) from a desktop 
PC via m-Router™ or a remote server via a Relay. This not only allows 
development and debugging of an mrix solution to be carried out from the 
convenience of a desktop PC but also allows smartphone components to be 
15 shared at runtime over networks. 

Some pipe processors are mandatory and are considered core to the system. 
Examples include mrEvent or mrAt which are used to start and stop processes 
based on events. A set of optional pipe processors are also supplied which can be 
removed from the runtime, if required, to minimise the memory footprint. 
20 Custom pipe processors can also be built in C++ or LUA Script and templates 

are provided for this. 



mrix Solution Examples 

See "mtix Features at a Glance" for more information on components used. 



Monitoring Spare Parts Availability 



Description 



Keeping an accurate inventory of tiie levels of spare parts carried 
bv a fi'dd ancin^r is 'iimculr. Bv combininir iott cost BlueEOOth 



mrix Solution 

• 

* 


mrBluetooth is used to easily manage the connectivity between a 
smartphone and a bluetooth enabled barcode pen. When die 
eng^eer needs a part, he/she "swipes'' the product barcode 
from a parts catalogue. A persistent inventory of parts is 
maintained on the device using mrStorage. Automatically, the 
smartphone indicates to the engineer the available stock on the 
van. If the part is not available, an SMS is created via mrMessage 
and sent to other engineer's smartphone^s. Using mrWatchFile on 

* 

the recipient's smartphones to trigger on receipt of a specific 
SMS message, the inbound SMS causes an inventory check to be 
carried out. If the remote engineer's phone indicates diat die part 
is available on die van, an SMS is automatically sent back to die 

m 

original engineer. On receipt of the SMS, a prompt automatically 
displays on the smartphone (mrPrompt) which informs the 
engineer that the part is available and supplies the phone number 
of the engineer with that part. The process can be further 
enhanced to only inquire of stock availability from engineers 
who are local using mrSim and the current cell-id. 


Components 
Used . 


Relay, mrBluetooth, mrStorage, mrMessage, mrWatchfire, 
MrPrompt, mrSim 




Sending an SMS ficom a PC 


Desadption 


Entering text messages can be tedious on a small smartphone. 
With mrix on the device, it is straightforward to build an 
application which would allow text messages to be composed 
from a Bluetooth connected PC and sent via the phone. 


mrix Solution 


Using m-Router and mrCmd, die smartphone is connected to 
the PC via Bluetooth. After authentication of the user 
(identities), a list of contact names and phone numbers is 
retrieved from die phone (mrContacts) and displayed on die PC. 



t 
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The user selects one or more contacts on the PC, enters the 
body of the text message and presses "Send SMS". PC 
application calls mrMessage with the data and the text message is 
automatically sent from the phone. 


Components 
Used 


m-Router, mrCmd, Identities, mrContacts, mrMessage 



Remote Smartphone Support 


Description 


Providing support to remote smartphone users can be a 
problem, mrix allows an operator with a remote PC (and 
permission from the end user) to take full control of a 
smartphone connected over a cellular network. 


mux ooiuuon 

• 


ine ena user runs a support appiication on tne smartpnone 
which automatically connects to a network hosted Relay over the 

• 

cellular network. The operator also connects to the Relay via an 
application on their PC. Once all parties are connected, the 
operator can connect directly to the smartphone. Using 
mrKeyboard and mrlmage, a real-time moving image of the 
smartphone's screen and a working visual image of the 
smartphone*s keypad are displayed on the operator's screen. 
Using mrPrompt, the operator is able to ask the user for 
permission to carry out certain tasks on die device. Using mrPS, 
the operator is able to see a list of the applications currentiy 
running on die smartphone. Using mrLavmch and mrShutdown, 
the operator is able to start and stop running processes and 
rcstint th^. Dhone rnmnr^hr. Usins^ mrSyoTofo, the operator is able 
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mrix Featxires at a Glance 



Need 



PC Connectivity 



Operation over 
remote connection 
(GPRS, WiFi etc) 



Security 



Data Storage 



Messaging 



Event Driven 
Operation 



Connectivity 



Feature 



m-Router™ 
mrCmd 



Relay 



Identities 



Sky Prive (remote) 
mrStorage (local) 



mrMessage 



Benefit 

Provides IP over serial link* AUows full 
control of device from connected PC over 
Bluetooth, IrDA, cable etc. 

Connects devices and server processes over 
firewall protected networks where devices 
are not "visible". Allows device on GPRS 
network to be discovered by otiier devices 
or services and facilitates "push". 



Users (or services) have to supply 
credentials to access commands on the 
device. 



mrWa 



A J. 



I 



mrEvent 



mrBluetooth, 
mrObex, mrTCP, 
mrThrou^put • 



Important data captured at the smartphone 
can be sent to an always available virtual 
storage device on the network or in tiie 
device. Data stored can be processed at a 
later time. 

Easy to monitor and manage the device's 
message centre. 

Trigger actions T-'hen certain situations are 
met. E.g. run script on receipt of specific 
SMS/MMS message. Also schedule 
operations to run at specified times. 

Create and manage connections over 
multiple bearers, examine and process data 
sent and received and measxire network 
performance. Send files via OBEX. 



t 
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Phone Infoniiation 


mrSvsInfo ' 


Returns device information including 
available drives, free space, format etc. 


Network 
Infotxnation 


mrSIM 


Retums network information such as IMEI, 
current cell-ID 2x^2. and Alobile Network 
Operator. 


1 Remote Control 


mrTmapp 

mrKeyboard 


Allow device screen to be Droiected to a 
connected PC and the keyboard of the 
smartphone to be controlled remotely. 


File Manipulation 


mrFile 


Easily manipulate the smartphone file 
svstem. 


Runtime Control 


mrPs, mrMr, 
rorBoot, 
mrShutdown, 
mrLaunch 


Query, start and stop processes on the 
smartphone; start applications automatically 
on boot and shut down a device. 


Data Capture 


mrPrompt 


Capture data from the user on smartphone 
via pop up dialog box. 


1 JrJJVL xJ2iX2L access 


mrcontacts, 
mrAgenda 


TT^ 11 1 11 1*. 111. f 

Full search, add, edit and delete of 
smartphone PIM data including contacts, 
calendar and memos. Possible to manipulate 
vcards, minivcards, uuids, speed dials, 
groups etc. 


Specifications 


Supported 
Operating SysremG* 


Sxnartphone 


Symbian OS v6.1, 7.0, 7.0s 

Kiicrosoft PocketPC Smnrtphone Edition 

1 
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Feature list 

The core mrix system contains a niimber of elements some of which are deployed on the 
5 smartphone: 

mrcmd: mrcmd consists of two elements, a coniinand interpreter for smartphones and a 
remote command execution shell. The command interpreter currendy runs on Symbian.^ 
The remote command execution shell runs on Windows, Mac OS X and Linux. 
10 m-Router®: Command-line interface to Inmwave's existing m-Router® product which 
handles local connection management on Symbian OS smartphones, m-Router®. 
operates over Serial, Bluetooth, USB and IrDA bearers. 

mrElay: mrElay consists of both a command-line interface to Intuwave's remote relay 
server and the relay server itself, Currendy the relay server can be accessed from the 
1 5 smartphone via GPRS or via a WAN proxied through a local m-Router® link. 

pipe processors: Pipe processors are small self-contained modules that encapsulate 
smartphone functionality. A small number of pipe processors that manage event 
Kanrllmg and file access are in the mrix core. 

script engine: A powerful and compact (60k) LUA 5.0 scripting engine is included on 
. 20 the smartphone to allow a developer to readily combine pipe processor functionality 
directiy using scripts. Included widi tiie scripting engine are a number of core mrix 
scripts that powerfully combine existing pipe processor functionality, 
mrix Reference Manual: HTML pages that explains how to use all the existing core 
pipe processors. There are also instmctions on writing new pipe processors as well as m- 
25 Router® and mrcmd functionality, docvunentation and example scripts detailing is 
included. 

We have a range of additional pipe processors that extend the core functionality of the 
system. These pipe processors can be readily added to an mrix system to enhance its 
■ 30 capabilities. 

The mrix advantage 



Areas of application 

miHy technology is directly applicable in a wide range of applications where remote 
control of a smartphone device is important: 

5 

Testing: mm enables full automation of system, functional, acceptance, regression and 
interoperability tests. 

PIM applications: m ri x enables rapid development of PC Connectivity PIM 
applications through script-accessible toolkits. 

10 

Benefits 

mrix offers numerous benefits to smartphone manufacturers and phone network 
15 operators. 

* Speed of development: mrix development is done in rapid iterations by 
evolving scripts rather than coding against APIs. This significantly speeds up the 
development lifecyde. 

20 * Cost: Since mrix functionality is script-based, the cost of development as well as 
the cost of maintenance and enhancement of functionality is significantiy reduced. 

* Cross-platform: mrix offers full cross-pktform support for smartphones. When 
combined witii a cross-platform toolkit, server applications can be built to run across 
different PC Operating Systems. 
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Appendix 1 

MRIX - Getting Started Guide 
MRIX Overview 

5 mrix is a platform agnostic ^xdreless network operating system. It is designed to allow 
rapid cross-platform development of a wide range of mobile applications both on and 
between smartphones, personal computers and servers. It consists of a powerful set of 
command-line driven tools which can be built upon and combined into sophisticated PC 
applications using scripting languages. In addition, mrix can be used to script applications 
10 that can be executed on tiie smartphone itself. 

Figure 2 shows a possible mrix architecture. 

mri-y consists of a number of elements which can be used to run commands over local 
15 links (IR, Bluetootii and USB) as well as via a remote relay (TCP/IP, GPRS) as illustrated 
in Error! Reference source not found,. 

* 

There are several key elements of die architecture: 

• • m-Routet: Bearer connection agent. m-Router consists of a number of botii PC 
20' and smartphone components. It enables communication between a smartphone 

and a PC over a variety of short-link bearers: IrDA, Bluetootii, USB and Serial 

• Relay: The relay, mrElayD (the T)' stands for daemon) allows remote access 
from a PC to a smartphone via GPRS. The PC and smartphone both connect to 
tiie relay in order for communication between them to occur. 

25 • Identity server All commands are run, whether locally or remotely, on behalf of 

an "identify*' (person or system). Different identities may be configured to run 
commands witii different results. . • 
•• Boot server. Handles mrix events to be siarted on smartphone reboot. 

• Command interpreter: A command interpreter module, rshd, runs on the 
30 smartphone and is normally set up to start up on boot. 



I 

* 
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• Cocomand shell: A command shell, mrcmd, mcis on the PC. The shell curr endy 
runs on Windows but will soon be available on Linux and Mac OS X. Programs 
and scripts can be written for the PC that communicate and interact with rnriv 
components on the smartphone. 

5 • Lua scripting engine: Scripts written in Lua ( http:/ /www.lua.org ) can be run 

on a smartphone. A number of useful scripts, e.g., SMTP and FTP clients, are 
provided with die release. 

• Pipe processors: Discrete smartphone modvdes tiiat can be accessed tiirough the 
mrix command environment to provide access to a range of smartphone 

10 functionality. 

Prerequisites 

Usage of mrix requires the following hardware and software: 
15 _ ? PC with IrDA or Bluetooth support - 

4 

• Microsoft Windows 2000 or later 

• m-Routet 

• mrix 

• Smartphone (Nokia 7650, 3650, 6600, N-Gage, SonyEadcsson P800) 

20 



Using MRIX 



m-J^uuccx — comsccting' to the smaripfaonu 

25 



« 
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To search for smartphones to connect to type 
>mrouter — c search-devices 

5 

This command option searches for all the Bluetooth devices in the locality. 

The first four columns listed are an arbitraty ordinal listing number used to represent the 
device, the UID (for smartphone devices this will be the IMEI number - in this example 
10 it is only shown for device 8), the Bluetooth address and the Bluetooth friendly name 
(assigned by the user of the device). 

Find your smartphone from the resulting list of devices then connect to the smartphone 
by typing the following command at the command prompt 

15 

>mrouter — c connect-device — d <Bluetooth device name> 

« 

For example if your smartphone has a Bluetooth name of Nokia7650 then the command 
wovdd be 

20 

>mrouter — c connect-device -d Nokia7650 
You will see the screen of the m-Router icon in die system tray turn from red to blue. 

25 You may find that for development purposes using the ordinal resulting from the 
"search-devices" is the most convenient You can connect to a smartphone using a 
variety of addressing schemes. The "-d" option takes the form <schema>:<id>. Schema 
can be one of N, IMEI, BTADDR, BTNAME, ANY. If not present, schema is assumed 
to be ANY. N will matdi against the listing number next to each device returned by list- 

30 devices or search- devices. IMEI matches die UID field. BTADDR matches Bluetoodi 
address. BTNAME matches device BT fiiendly name. ANY matches all the above. So, 
it is possible to connect to a device in various ways thus: 
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>inrouter -c connect-device -d 8 
>mrouter -c connect-device -d IMEI : xxxxx x xx xyy 
>mroui:er -c connect-device -d BTADDR ixxxxxxxxxx 
>mix)uter — c connect-device — d SJC xxxxxxxxx 

To disconnect firom the smartphone, type 

>mrouter — c disconnect-device — d <Bluetooth device name> 
You can also type 

>mrouter — c disconnect-device — d . 

where a period stands for the currendy connected device or the first connected device if 
more than one device is currendy connected. 

mrcmd - controlling the phone firom the PC 

mrcmd is a PC side program that allows you to run pipe processors and scripts on die 
smartphone. Before running pipe processors and scripts on the smartphone it is 
necessary to set up the requisite level of security for your mrix setup. This is done by 
setting the mrcmd environment variable. At present, identity configuration information 
is stored ia the \system\mrix\identity.ini file on die smartphone. A CTO identity has 
been set up in this file with a password of GOOD. You should use this identity for 
playing with the mrix system. This can be done firom die DOS command shell as follows: 

> set mxcind=-} «ZTO -a GC>OD 
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Enter MRCMD' into the "Variable' field and ^-i CTO -a GOOD' into the "Variable 
Value' field. 

Click OK three times to save the change. 

Once security has been set up, you will need to start up die remote shell daemon, rshd, 
on the smartphone. You should only have to do this once the first time you run mrty on 
the smartphone. Thereafl:er, rshd will be automatically started at boot using the mrtV 
boot server. To run rshd, you need to open the mrix application on the smartphone and 
execute the first command'in the list box which should be: 

mrtcp 

—accept —local 301 1 -run "rshd -run" 

The mrix apphcation is a simple way of running commands and scripts on the 
smartphone. To invoke another command firom mrix just simply overwrite an existing 
command liae (and any necessary parameters). 

Now you are ready to try nmning an mrix command \ising mrcmd over an existing 
mRouter cojonection. You may try out any of the wide range of existing pipe processors; 
mrps and mrfile will be described here. 

Connect to the smartphone using m-Router. 

To view all the processes running on the smartphone, type 

>mrcmd . "mrps -1" 

mrcmd tells the smartphone (m dais case denoted by a period which means the currently 
connected device but you can be explicit and specify the Bluetootii name) to run the 
mrps pipe processor with the -1 option. Notice that the command is enclosed in double 
quotes. 

* 

To get help on mrps fix>m the command line, type 
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>mrcmd . "nups -h" 
To send a file to the smartphone, type 

>mrcind . "mrfile -w c:\system\default.car" < c:\mrix\bin\defa\alt.car 

This command redirects a file (c:\mrix\bin\default.car) to the smartphone. The '-V 
option specifies where on the smartphone the file should be written 
(c:\system\defaultcar). 

To delete the file firom the smartphone type 

>mrcmd . "mrfile -d c:\system\default.car" 
To get help on mrfile firom the cotnmand line type - . . . 

>mrcmd . "mrfile -h" 

■ 

Lua scripts can also be invoked using mrcmd. To get help on running lua scripts firom 
the command line, type 

>mrcmd . *luarun -h" 

Create a script file called testlua and copy and paste the text between (and not including 
the chevrons to the file 



* 
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res = xnnx.xunCxD£ptompe\ "-t YESNO -p \"Need helpPX"'*) 
innx.writeC*Result = "..res.."\n'^ 



5 Lua scripts can be run on the smartphone in one of two ways: 

• by streaming a lua script to the smartphone 

• by running a Ixia sctipt that resides on the smartphone. 

To stream the script to the smartphone, type 

10 

>mrcmd . *luarun < testiua 

The script will print, "Hello, Worldl" at the command line. By this method the script 
does not have to be resident on the smartphone. 

15 

To run the script from the smartphone, first write the script to it 
>mrcmd . "mrfile -w c:\system\mrix\test.lua" < test.l\ia 

20 To run the script, type 

>mrcmd . 'luarun c:\system\mrix\ testiua'* 
The result is the same as running the script by the first method. 

25 

Lua can be invoked interactively as in the followmg example thus: 

>mrcmd . *luarun" 
>n^.write("HeUo, Woridl'O 

30 >q 



o 



t 



■ 
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For help on lua, check out the following resources: h ttp:/ /www.lua.orgj http;//lua- 
users.org / wild /Tnf-Qriainirerfrtry Review Intuwavc's extensions to lua in the mn'Tc 
documentation. 

5 More On Scripts 

There are two ways to run a Itia script on a smartphone independent of interaction with a 
PC. 

10 The first is to invoke it using the mrix application. Simply type the name of the script in 
the Cmd field and any parameters for the script in the Params field and select Run, 

The second is to have the script run when the smartphone is turned on. To do this you 
have to setup an event that loads the script into the boot file of the smartphone: 

15 

>mrcmd . "mrevent —a — n runmyscript -e BOOT -c luascript.lua" 

This command adds (-a) a boot command (-e BOOT) to the boot file of the smartphone 
to run a script (-c luascript Jua) when the smartphone is turned on. The event is given a 
20 name (-n runmyscript) that acts as a handle such that it can be removed firom the boot 
file thus: 

■ 

>mrcmd . "mrevent ~d — n runmyscript" 
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Identities 
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So far we have run commands via mrcmd using the user, CTO (which has full 
permissions for all commands). If a smartphone is setup to run a script when it boots 
then the default identity it will use will be "Guest" which has minimal permissions. The 
script will therefore be limited in the mrix commands that may be run. To do anything 
5 useful the identity must change so that the script may take on more permissions. Edit 
the lua script file you created earlier. Copy and paste the text between (and not 
including) die chevrons to the file. Then use mrfile to send the script to the smartphone 
and run it using the mrix application. In mrix select Options | Run, enter "testlua" into 
the Cmd field (make sure the Params field blank) and select Run. You will be presented 
10 with a prompt to which you may select yes or no. 



#!luarun 



15 — save the current identity, in this case, Guest 
oldjid = nudx.getcurrentidentityO 

— make a new identity handle using the CTO usemame 
newjd = mrix.makenewidentity("CTO", "GOOD'O 

— use t-Vii<; newly created identity to run the following commands 
20 mrix.setc\irrentidentity(new_id) 

mrix.write(**heUo, woridl\n") 

— run the mrprompt pipe processor 

— mrix,run runs other scripts and pipe processors and has the form 
25 — mrix.run(command, command parameters, [optional input]) 

res = mrix.runC'mrprompt", "-t YESNO -p \"Need helpPX"**) 
mrix.writeC*Result = '\.t&sJ\vJy, 

— restore the saved identity 
30 mrix.setcurrentidentity(old_ic^ 

— release the new identity to free up resources 
mrix.releaseidentity(new_id) 
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Appendix 2 



Pipe Processors 



mtAgenda provides an interface to the agenda database 



nuAt schedules commands to run at given times 



inrBluetooth provides access to a range ofBluetootii services 



tntContacts provides an interface to the contacts database 



nuJBlayd establishes a connection to a relay server 



mrEvent sets up and fires events (commands) 



mrFile performs basic file and directory operations 



mrlmage captures a single image or stream of Images firom the device 



mrKeyboard simulates keyboard character entry 



mrLaunch starts applications, lists installed/running applications 



mrMessage view/delete messages, send SMS, watch inbox 



msrMr retrieves information regarding other pipe processors 
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tnrShutdown shutdown, reboot or see boot status of device 



mrSim 



retrieves sim related information 



mrSky 



stores data on an 'always available* storage area on the internet 



mrStorage 



allows data to be stored on the device 



mrSysinfo 



returns system information 



mrTcp 



Establishes TCP/IP connections 



mxThroughput tests throughput to and from phone 



mtWatchfire runs commands when watched resources change 
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Appendix 3 

Developing Symbian Pipe Processors 

1. Introduction 

This document is intended to operate as a guide for all developers wishing to write 
S3rtnbian pipe processors. It covers the basics of getting started using the mrix pipe 
processor template and also discusses some of the common patterns that may be 
encountered during pipe processor development 

2. What is a pipe processor? 

A pipe processor is a smartphone based module that encapsulates a logically related set 
of smartphone functionality. They are so named because they abstract all their input and 
output through an mStreatii derived interface. 'That is, they essentially preseiit their 
functionality through a command line interface. For example, the mrContacts pipe 
processor abstracts all aspects of Contacts management on a smartphone. If rm<!}ontacts 
is invoked with a -1 option, it returns a /£r/of all contacts. If it is invoked with a -p option, 
it expects a file of contact information which it will use to update the Contacts database 
on the smartphone. 

On Symbian, pipe processors create a single instance of a 
CmStreamProcessorlnstanceGroup derived dass which in turn can be used to create any 
number of CmStreamProcessorlnstance derived instances to manage specific tasks. 
Typically a separate CmStreamProcessorlnstance would be created for each significant 
command line option. Pipe processors can be designed as stand alone entities or can 
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running on the device. In general, it is a good idea to design pipe processors to be 
logically self-contained modules responsible for distincdy separate aspects of smartphone 
functionality. In other words, pipe processors should be kept as "ordiogonal" as possible 
and designers should avoid attempts to shoehorn different sorts of responsibility into a 
single module. 

Common features of all pipe processors on Symbian: 

1. Polymorphic DLL with single export diat returns a pointer to a pipe processor 
group. For mrContacts this is: 

CmStreamProcessorlnstanceGroup* CmrContactsGroupCreatorFunction (const 
mStreaniMantiFixedStting &aName) 

2. UID 1 is OxlOOOAFVO 

3. Responsibility for some discrete aspect of smartphone functionality 



3. Getting started with pipe processors 
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The auax pipe processor template 

The recommended way of building a pipe processor is to start with the mrix pipe 
processor template, commandtemplate.pl which you can find in 
\mrix\source\epoc\generic. You invoke this template with the intended name of the 
pipe processor from a DOS shell command line together with an appropriate UID2. The 
valid range of UIDs for development is 0x0000000 1-OxOfffffff. UIDs in diis range 
should NOT be used for released code. Instead, third party developers will need to 
consult ^ Symbian technical paper. As an example, in order to create a template pipe 
processor, mrFoo with a development UID of OxOOfDOfOO, run the following command 
in the \mrix\source\epoc\generic directory: 
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dtemplate.pl -n mrFoo -u OxOOfflOfiOO -s templates\synchronous_pp 



« 
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On running this command you should find MSVC6 being launched with a skeleton 
project. Within that project you will find a ready made template mrFoo.html man page, 
empty todo.txt and history.txt files and also a number of C-f + soiirce and header files. 
You should be able to compile and build the pipe processor both within MSVC6 and 
5 firom a DOS shell command line. In order to build the pipe processor for a Symbian 
sinartphone, you will first need to change directory firom \mrix\source\epoc\generic to 
\mrix\source\epoc\generic\mrfoo\group. Now invoke the thximb variant build as 
follows: 

10 

abld build diiimb urel 
and ttansfer die pipe processor to an appropriately connected target as follows: 

15 

putpp . mrfoo 

Note that in order to do diis you will need to ensure that an m-Router® connection is 
active between the Symbian smartphone and the PC and that the mrix remote shell 
20 daemon rshd is running. The details of how to do this are outside the scope of this 
doctiment but may be foimd in a companion document entitied mrix Getting Started 
Guide. 
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Ciicc LUC pipe pTDeessor mrFoo is on the Jeviec, it is necessarylxi modify the identityim 
file on die device to allow your identity to run tiiis pipe processor because by default you 
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FoUo\wng a reboot of the phone to ensure that the identity server is able to register the 
upgrade, you shovild be in a position to run the pipe processor. 



The built-in help for mrFoo can be invoked as follows: 



mrcmd . "mrfoo -h" 



At this point, you have a mrFoo pipe processor running on the Symbian smartphone. 
You should be able to see it appear as a legitimate pipe processor in the mrmr -1 Usting of 
system pipe processors. Support for the foUowing options is built in as default by the 
template: 



* -h: help listing 

* -v: verbose 

* -V: version 



The process of getting firom invoking tiie command template to having a working pipe 
processor installed on tiie system should take less than one minute. 



library support 



Pipe processors link to the foUowing three libraries: 



30 * 



mStreamClientExJib: mStream classes 
mStreamProcessorExJib: mrix pipe processor extensions 
mStreamUtiIEx.lib: mrix pipe processor utilities. 
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The headers that correspond to these libraries are as follows: 

* #indude <niStreamClientEx.h> 

* #inciude <mStxeamProcessorEx.h> 
5 * #include <mStreamUtilEx.h> 

Note that if you use the mri^ pipe processor template, these libraries and headers will 
automatically be inserted into the relevant files, namely the .mmp make file and the 
stdafe.h header file. 



4. Architectural elements 



IS Invoking other pipe processors 

The following code snippet illustrates how to create an instance of a 
CPipeProcessorRunnerContainer and use it to determine the version of a pipe processor 
using the standard -V option: 

20 

runner= CPipePro cessorRurmerContainer: rNewLQ ; 
Tint handle = runner->PPOpen(aPP,JL("-version")); 
InfoC-L80*PPOpen returned %d'%handle); 
25 iVersionBuffer.SetLengdi(0); 

if (handle > 0) 

{// Synchronous read of PP output, until end of file 
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if Oerr) 

iV ersioiiBuffe£+=bu^ 

} 

err=runner->PPaose(handle); 
InfoCJLSC'PPClose returned %d"),crr); 
delete runner; 



10 

5. Pipe processor design patterns 

There are four common types of processing that can occur witiiin a pipe processor: 



15 * list processing 

* Input processing 

* Connection management 

* State management 

20 Each of these architectural use cases can be handled using a specific pattern outlined 
below. 



25 Note that this section is sHU under construction. 



List processing pattern 

Ifisert text here on dealing mtb during of large amounts of data to mite pipe. Double buffering for 
3 0 professional touch. 



Input processing pattern 
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Insert text here on how to slurp up and ^namically process input Discuss cons of waitingfor all itput to 
get in as opposed to handling the stream inline. Gotbcha on stream data -you need to implemetit a state 
machine to handle input data state. 

Connection management pattem 

Ou^oing connections should be managed by separate instances. Inmning connections should be hung off 
group => inetd tjfpe c^proach. 

Status management pattem 

Transient/ bursty instance that provides quick status report. 
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Appendix 4 
S mrix command and script guidelines 

1. Introduction 

10 This document lays down guidelines for how mrix commands (including both C++ pipe 
processors and scripts) should be written and how they should operate. It is iatended for 
both die writers and testers of diese commands. 

2. Common to pipe processors and scripts 

15 

The foUowiQg guidelines apply to both pipe processors and scripts: 
2.1 Input / Output format 

20 Data input or output by commands intended to be coming from or processed by other 
software should be accepted / available in at least one of the following formats: 
MIME type Descriprion Example 

text/comma-separated-values List of records widi fixed ntimber of fields. First record is 
header record. 
25 mrps -L, mxouter -c list-devices 

text/x-mrix-versit Tree or flat structure iist of records with possibly varying number 

of fields. 

mrconlacts -1, mragenda -1, mrmessage -1 
text/x-mrix-tagged Static list of 'labehvalue' pairs, used where a single static record is 

30 output each time mrsim -i 

application/octet-stream Generic binary data, in command specific format 

« 

mrfile -r, mrimage, mrtcp 
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2.2 Etroxs, Warnings and Information 

All error, warning and information messages shoxild by output on standard error, the aux 
output pipe. They should be in one of the following formats: 
5 Format Usage 

ERROR: Error message A fatal error which means operation of the command 
cannot continue. After outputting an ERROR message the command must stop 
immediately. 

WARN: Warning message A diagnostic error which means something that the user 
10 should be alerted about has happened, but operation of die command can continue. Use 
sparingly. 

INFO: Information message A diagnostic message to help clients of your command 
while they are debugging their own software. Any messages used to debug your own 

■ 

command should be removed before releasing. INFO messages should only be output if 
15 the user has selected the VERBOSE command option. Use sparingly. 

Special attention should be paid to any data output on standard error. You should never 
output more than 4K of data otherwise clients may deadlock unless they are reading both 
your output pipes simultaneously. 

20 

23 Return value 

A successful run of a command should result in a return value of zero. If an error occurs, 
the return value should be set to the appropriate (negative) error code. A list of error 
25 codes is provided here . 



2.4 Patterns 
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Input only On execution the command reads data either from standard input (until 
EOF), or a file, or the command line then processes it. No data is output 
Input then output On execution the command reads data either from standard input 
(until EOF), or a file, or the command line tiien processes it. Afterwards some data is 

output- 
Watcher On execution the command runs and starts monitoring some system 
resource. Every time tiiat resource changes, it VTill print 'changed' and a newline. The 
command \viU also read its input pipe. If the pipe is closed, or die text •quit' is sent, tiien 
the watcher will exit. 

Stream lO On execution the command will both read and write, according to some 
command specific rules. 



2.5 Line Terniinators 



15 On output, all commands will terminate lines with a \r\n character pair. All commands 
which accept input in text format will understand lines which terminate dtiier \r\n or 
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2.6 Addressing other devices 



If a command is required to address other devices then it should allow a number of 

different schemes for doing that The scheme is appUed by referring to the device as 

SCHEME:NAME. The default scheme is AJSHT if there is no scheme attached to the 

device reference. 
25 Scheme Description 

N If the command outputs a list of devices numbered ftom 1, tfecn the N scheme 

allows a dient to refer to a specific device in die list by its number in daat Ust. 

BTNAME References a device by its bluetoodi name. It is the client's responsibility 

to ensure that the name is quoted and escaped as necessary. 
30 BTADDR References a device by its bkietoolii mac address. The command should 

understand the address wida and widiout : delimiters. 

TMRT References a device by its IMEI number. 

ANY Tries to find a matching device by any of the above schemes. 



?4 



I 36 

2.7 Standaxd options 

» 

All commands must support options in long (posix) and short forms and tiiey must at 
5 least support the following options: 
Option Description 

-h, —help Display short usage text listing the command options and very brief 
explanation if there is room. The text output by -h should be no greater than 1024 hjtcs. 
-V, —version Display version information in the following format: a.b.c (d) (e). a,b,c, d 
10 are the version and buUd number of mrix against which the coxnmand was built e is a 
command specific version number which is incremented at every revision of the 
command, 

-V, —verbose This command enables informational output about the command to be 
displayed. This information should be there solely for the benefit of finding problems in 
1 S client programs, not debu^;ing the command itself. 

No option No command line options should cause the command to print an error' 
and default to the help option. 

In addition, many commands provide a —list, -1 option as the primary inspection or 
20 display mechanism. 

2.8 Additional files 

* 

As well as the command itself, the developer should supply a html format man page to 
25 explain in detail the command's purpose and operation. The developer should also 
rr^gfritair! a history.txt file (to record what has changed in each version of the co mman d) 
and a todo.tst file (to record thoughts for upcoming versions). 
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3. Pipe processors only 

The following guidelines apply to pipe processors only. 
3.1 Memory usage 

All pipe processors should be written with an eye to minimising memory usage. 

10 Objects should only be created if they are required by the command line used, e.g. 
running mrAgenda -V should not cause the command to connect to the Agenda server. 

You should make good use of yovir 16k stack available. 

# 

* 

1 5 Use CBufFlat instead of large TBufB's if you need to output large strings of data. 

If you need to output more than 1 6k of data, consider outputting asynchronously in ■ • 
chunks. 

m 

20 3.2 Outputting data 

Pipe processors should build up their data to be output in a single buffer, then output it - 
don't call WritePipeL over and over again. 

25 3.3 International support 

Pipe processors should convert all UNICODE data to UTF8 before outputting it using 
the built in character conversion facilities of the platform. 

30 4. Scripts only 



The following guidelines apply to scripts only. 



4.1 Local 

Make all yoxir variables local 
5 4.2 Etror codes 

Make sure you always check the error codes of pipe processors you calL 

« 

Set your own error code as appropriate (we need to add a way of doing this) 

10 

4.3 Memory usage 

Process data a line at a time where possible, rather than slurping 
15 4.4 Debugging 

All scdpts, even those designed to be run from other commands, should be ruimable in a 
local context to allow for debvigging» 

20 
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Appendix 5 

5 mrix and the smartphone testing environment 

■ 

1, Summary 

This paper outlines a number of opportunities for employing mrix to assist Symbian OS 
10 smartphone manufacturers improve the quality and quantity of product testing. This 
testing is conducted during the long period of Symbian OS smartphone development 
that occurs prior to product shipment The opportunities arise because of the overtly 
manual nature of the majotity of testing done today, 

15 2. Overview 

2.1 Issues with smartphone testing today 

The testing of a Symbian OS smartphone during the long period of its development is a 
costiy and painful exercise today. The process is heavily reliant on ad-hoc, manual and 
20 non-repeatable testing. 

Issues with the testing of Device Applications 

* Majority of tests are done manually 

* Long running tests and stress tests are almost impossible to do in an automated 
25 fashion 

* Data generation on the device is a painfui and tedious exercise 

* Tests are not readily repeatable 

* Constant reflashing of ROMs during development cyde causes many of the more 
difficult or long-running tests to "fall tiirough the cracks" 

30 

Issues with the testing of Coimectivity Software 
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All the above issues apply eqxxally to the testing of smartphone Connectivity software. In 
addition, because connectivity involves establishing a link between a PC and the 
smartphone, there is a further complication in that simultaneous control of the 
PC/Server and smartphone is not currently possible. 

5 

2.3 The mrix advantage 

Smartphone device manufacturers' priorities in terms of product testing are as follows: 

10 

* Smoke testing - testing basic UI functionality 

* Aging system tests - adding/removing/modifying entries thousands of times 

* Localisation testing - testing 

* Operator testing - phone network interoperability testing 

'15 



In terms of the above list, mrix brings a vital additional element to the testing arena, 
20 namely the ability to remotely control potentially multiple Symbian OS devices. Remote 
control dramatically Increases the scope for automation of testing and this in turn wiU be 
attractive to Symbian OS smartphone manufacturers because it should enable them to 
improve both the quality and quantity of testing while simultaneously reducing cost 

25* 3. Potential testing opportunities for narix 

The following arc concrete suggestions for prototypes that wottld help illustrate the 
ndvanta<^es of using mris as a basis for Symbian OS smartphone device testing. The 
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of smartphone testing throxigh the introduction of Developer Certification programs. 
There's a risk that a third party Symbian OS developers may become overwhelmed by the 
cost of all the certification. Ideally they'd like to have a cheap and easy way of sanity 
checking their application. 
5 

The Application Tester would automate the process of testing a Symbian OS application. 
This would require the implementation of screen validation support in mrix which could 
prove time-consuming but is probably essentially not only for the Application Tester but 
for many of the following opportunities. The support would probably involve 

10 implementing a pipe processor that is able to interact much more closely with Symbian 
OS wserv to allow a remote script to direcdy control input to an application and test its 
screen output. It would need to involve something similar to the Qtrix protocol iwtii 
GDI object information being passed over the mrix link. The current approach taken by 
mView involves passing screen bitmaps over the Hnk. 

15 \ 

3.2. Smoke Tester 

% 

Smoke testing probably gets repeated more tiian anytiiing else during die testing phase. It 
20 is a cmdal activity because it is die primary indicator used to determine whetiier a build is 
suitable for fiirther beta testing. In otiier words diey have a vital role as an eady warning 
of regression. Today, smoke testing is almost exclusively manual. It usually takes the 
form of a tester enacting a range of appropriate use cases on the smartphone such as 
sending an email or browsing the web. 

25 

The mrix "Smoke Tester" would automate the whole smoke test procedure and indicate 
to a tester whether the build passed or failed. The tests could eitiier be run fi:om a script 
that used a variety of separate pre-existing pipe processors or they could encapsulated 
within a single pipe processor. In either case, the range of testing conducted for a typical 
30 smoke test should be enhanced to ensure that the barrier for acceptance for fiartiier 
testing is raised. In due course, there is no reason why the Smoke Tester might not be 
enhanced to evolve into a full blown system tester. 
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3.3. The Aging Stress Testet 

Given that most smartphone testing is conducted manually, aging tests are particularly 
difficult to conduct. These involve simulate the use of die smartphone over an extended 
5 period of time. Smartphone manufacturers would be very interested in anj^diing that 
could help them improve quality through aging tests because it could help them avoid 
very es^ensive product recalls. 

The mrix "Aging Stress Tester" would simulate the process of aging by compressing for 
10 example 6 months of typical usage into a much smaller amoimt of time. This would 
include a whole range of user operations such as periodic insertion and occasional 
removal of contacts, agenda and email entdes. The tests wcould be run using pre-existing 
pipe processors or by encapsulating tiiem within a new stand-alone pipe processor. In 
eidtier case, it should be easy to modify the tests daat are run through a script. 

15 

4 

3.4. The Test Code Harness 

Symbian OS component test code is typically written in die form of a test harness that is 
20 frequentiy automated. As such, tiiere is a fair amount tiiat it should be possible to do in 
order to template such test code. In addition, moving component interface test code 
witiiin a pipe processor raises die possibility of testing Symbian OS components entirely 
throiigh scripting. 

25 The mriy "Test Code Harness" would raise the game regarding component and interface 
testing. The harness would be in the form of a template pipe processor that could be 
filled in with the appropriate inter£a.ce functions and then driven through a script 
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Generating sample data on a smartphone today is a frustrating, limited and mainly 
manual procedure today. In particular, it is particvilady difficult to generate varied data 
sets. 

5 

The Data Generator would automate the process of data generation by using either a 
stand-alone pipe processor or a combination of pipe processors to handle die device side 
work and a flexible script interface to vary the data set. 

10 

3.6. Connectivity Tester 

Testing smartphone connectivity is an inefficient and mainly manual procedure today. 
Symbian OS Smartphone manufacturers have traditionally really stru^ed with this area, 

15 

The Connectivity Tester would automate the process of testing the Symbian OS 
Connectivity conduits by integrating basic mrouter, conqjro, backuppro and agendasync 
testing using a number of pipe processors and a set of test scripts. 

20 

3.7, Phone Network Stress Tester 

In order to gain Network Operator approval, it is necessary for a smartphone to undergo 
extensive interoperability testing. It is our understanding that Symbian OS Smartphone 
25 manufacturers have traditionally stru^led with gaining operator acceptance. 

The Network Stress Tester would automate the process of testing against Network 
Operator acceptance criteria. It would consist of script support implemented against a set 
of pipe processors that would allow the testing of SMS; MMS and phone network 
30 functionality. This opportunity could initially be built upon Rob C*s SMS tester script 
which already demonstrates the power and flexibility of mrix in testing in a multiple 
device context. 
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4. Related opportunities for mrix 

There are a number of areas closely related to testing which offer some good 
opportunities for Symbian OS smartphone manufacturers to deploy mrix technology. 
5 Specifically, field testing, diagnostics and debugging appear the most proinising. 
Additional areas of interest could be ID£ integration and the activity of product 
development itself. 

4.1. Field Diagnostics Dumper 

10 

During field testing, it would be extremely useful for users to have a means of providing 
really comprehensive diagnostics firom the smartphone imder test to assist in defect triage 
and debugging. 

15 The Field Diagnostics Dumper woxald be a pipe processor and small accompanying utility 
that could be used to provide qviick aiid comprehensive diagnostics firom the device 
under test. 

20 4.2. IDE integration 

Dviring pipe processor development, it has become clear that mrix has the potential to 
considerably speed up product development. The putpp utility alone has proved very 
handy for rapidly updating a pipe processor. There may be potential for partnering with 
25 an IDE tool vendor to develop a combined IDE with mrix inside that provides a more 
sophisticated development environment than is cnrrendy the case. It should be noted 
that this airea has die potential to develop quite considerably but probably needs a lot 
more iavcniniiizir fecm us m r^'-m-r c f izic ipf-t ~.i±ort Lzzolz it -^i do. so. 
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CLAIMS 

1. Method of rapid software application development for a wireless mobile device, 
comprising the step of calling modialar software elements, that each (i) encapsulate 

5 £unctionaIit7 required by the wireless mobile device and Qx) share a standard interface 
stmcture and (m) execute on the device, using a high level language program. 

2. The method of Claim 1 in which one or more modular software elements 
encapsulate device networking functions. 

10 

3. The method of Claim 2 in which the device networking fianctionality relates to 
connectivity over one or more of die following: GPRS, 2G cellular, CDMA, WCDMA, 
Bluetooth, 802.11, infta-red, IP networking, dial up, and modem. 

4. The metiiod of Claim 1 in which one or more of the modular software elements 

« 

encapsulate general mobile device functionality. 

• * 

5. The method of Claim 4 in which the general mobile device functionality relates 
to one or more of the following: call control and handling PIM functionality, SIM 
functionality 

6. The method of Claim 1 in which the high level language program runs on an 
application development computer remote from the device 

25 7- The method of Claim 6 in which the high level language program runs on the 
device itself. 

8. The method of Claim 1 in which the standard interface stmcture of a modular 
software element is the name of die element and a set of options. 

30 

9. The method of CAii\m 1 in which the high level language is not restricted to a 
single type of high level language, but can be any of tiie following depending on the 
requirements of the developer of the software application: 



15 



20 
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(a) a command line interface 

(b) a scripting language 

(c) a compiled language 

5 10. The method of Claim 1 in which the high level language is a command line 
interface. 

11. The method of Claim 1 in which the high level language comprises scripts. 

10 12. The mediod of Claim 1 in which the high level language program can in addition 
run on the device, to enable re-programming of the device without the need to use a 
separate application development computer. 

13. The method of Claim 1 in which the modular software elements insulate the 
15 application developer from the specifics of the operating system of the device by 
requiring the application developer to understand the type of functidhality to be 
deployed and not the specific operating specific code needed to implement that 
functionality using the operating system. 

20 14. The mediod of Claim 1 in which the device runs a command interpreter and the 
appHcation development computer runs a command execution shell 

15. The method of Claim 1 in which the application development computer is 
connected to the device over a local point to point IR, Bluetooth, USB, WAN, LAN, 

25 SMS or GPRS or any combination of these. 

16. The method of Claim 1 in which modular software elements can be chained 




1 



47 

18. The method of Claim 17 in which there is an identity server with secure 
permissions that provides and controls the identity and associated permissions. 

19. The method of Claim 18 in which the identity server is located on the device. 
5 

20. A software application developed using the method of any preceding Claim 1 — 
19. 

21. The software application of Qaim 20 which is initiated or controlled from the 
1 0 remote application development computer. 

22. The software application of Claim 20 or 21 which is accessed or controlled by die 
remote application development computer in a secure fashion. 

15 23. The software application of Claim 20 which runs stand-alone on the device 
without any initiation or control from the remote application development computer,.;. 
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